Increasing Planning Efficiency and Modelling Expressiveness through the Use of Pairs

We discuss the use of variables during the planning process as a means of extending the use of least commitment. We show how the use of typed constraints between variables, which we call ‘pairs’, can improve both the efficiency of the planning process and the modelling expressiveness of planning operators. Finally, we report on experiments using pairs in the Chemical Engineering Planner, CEP, and the issues involved in acquiring knowledge for pairs. 1.0 Introduction In this paper we discuss what we see as a useful addition to a planner, the facility we call pairs, or a typed constraint between two planning variables. This arose as a result of applying AI planning to a specific domain: that of generating operating procedures for chemical process plant, using the Chemical Engineering Planner (CEP) developed from 1993 [Soutter 97] and latterly during the project INT-OP [Aylett et al. 97]. However, while this domain poses specific planning problems [Aylett et al. 98], we believe pairs are a generic facility, which can be useful in many other planning domains. Pairs can be seen as a straightforward but useful extension to the expressiveness of the STRIPS formalism still widely used in planning. Recent work [Long & Fox 98] distinguishes between three types of extensions to STRIPS: purely syntactic extensions, which make domain description easier but do not change its scope; extensions which allow new domain properties to be represented [Erol 95]; and extensions which allow extra domain-specific knowledge to be represented so as to reduce the search problem for the planner in some way. Pairs are an example of this third type of extension, which, like the second type, requires associated changes to the planning algorithms used. We first discuss the use of variables during the planning process and go on to explain how pairs have been implemented in CEP. We then discuss their impact on the modelling of process plant domains and consider a small-scale experiment to quantify the benefit of using pairs in this domain. 2.0 The role of variables during planning A basic facility of planning languages is the use of variables in the specification of planning operators. In the discussion that follows, we use a leading ‘?’ to indicate a variable. For example, we can write an operator to model a block ?x being moved from the table to the top of another block ?y. These variables are just a language construct for operator specification. We do not usually allow them to appear in the finished plan. A finished plan must move specified blocks to specified locations. Most planners also have a data structure that represents a variable during planning. For example, when a move block operator is instantiated to become say, action number 11, then a variable ?x-11 is created to represent the value of ?x in this action. For clarity, this paper will refer to the variables used to describe operators as “operator variables” and the variables used during planning as “planning variables”. In theory it is possible to create planners that do not use variables during planning. Each time an action is created from an operator we simply instantiate all the variables in the operator by choosing possible values. All alternative values can be tried through backtracking. However the use of planning variables is a way of reducing commitment because they allow the planner to reason at the same time about several different instantiations of the actions in the plan. In this way, planning variables are an important tool for improving the performance of a planner. This paper is concerned with the intelligence that can be built into planning variables to help improve planning performance. We provide a new and simple way to make planning variables more intelligent by supporting a new constraint between them. If we allow new constraints between planning variables then it is relatively easy to support these constraints in the operator language for operator variables also. Hence our proposal also helps in the modelling of operators as we see below. However, it is not necessary in theory to use our intelligent planning variables in order to support intelligent operator variables. The earliest planners, including STRIPS, represent planning variables as a receptacle that can hold a value or another variable or nothing. A useful aspect of STRIPS variables is that they support co-designation. A goal on(?x-5,table) can be solved by a goal achieving on(?z-6,table)without binding ?x-5 or ?z-6 to particular values. This is important if the solving action has preconditions which also involve ?z-6 because the planner is still free to solve the precondition for any value of ?z-6. Later planners also allow non-codesignation constraints between variables and values. Examples are Chapman’s TWEAK [Chapman 87] and Weld’s POP [Weld 94]. Noncodesignation constraints occur when the planner seeks to prevent an action from clobbering the achievement of a goal. For example, to prevent an action with the effect on(?x-3,blue-block) from clobbering the achiever of on(?z-6,table) the planner must ensure that ?z-6 and ?x-3 are separate objects by applying a non-codesignation constraint. [Weld 94] presents a simple implementation of variables that support non-codesignation constraints. In this implementation, an extra list field is added to the data structure for a variable. Non-codesignated variables and constants are stored in this list. A variable may not bind to a value if the value matches any constant in the list or the value of any variable in the list. Note that, in this implementation, non-codesignation constraints between variables are really only processed properly when one of the variables binds. The use of non-codesignation constraints can allow absurd plans to be represented. For example, a variable ?light-21 can be constrained to be neither on nor off. Similarly, a variable ?peson-21 can be neither alive nor dead. These absurdities might not be discovered until the planner attempts to ground the plan at the end of planning. Hence, it is possible for the planner to do a lot of work refining an absurd plan that clearly will never solve the given planning problem. As a result, some planners allow variables to be constrained to a set of possible values. Inconsistency can then be discovered more quickly because the planner can watch for variables that have exhausted their set of possible values. In a finite domain, associating a variable with a set of possible values is the same as giving that variable a type. For example, associating ?p with the type “person” is the same as restricting ?p to the finite set of people that are known to the planner. The use of typing is not sufficient to prevent variables from representing impossible values. For example, it is possible for the planner to intend to share two possible values with three mutually exclusive variables. In general, it is an NP-Hard problem to decide if a set of variables can satisfy their typing and non-codesignation constraints [Chapman 1987]. Chapman argues that typed variables should not be used for this reason. However, in finite domains, untyped variables suffer from the same problems as typed variables, it is just that these problems are not explicit in the model. While the task of choosing acceptable values for typed non-codesignated variables is NP-Hard, this task is not performed very often in planning. Most planners only attempt to ground a plan at the end of planning. At this point, there are usually very few unbounded variables and the task of satisfying these variables is not very difficult. The planner is not concerned with the problem of assigning values to variables during planning. Instead, the planner is simply concerned with whether a variable can bind to a particular value – e.g. whether a goal can be satisfied by an achiever. This simpler task can be completed in polynomial time1 even if non-codesignated, typed variables are used. The use of typed variables then is a way of replacing a usually exponential time task of refining an absurd plan with a usually polynomial time but at worst exponential time task of assigning values to a set of variables. As a result, this trade off is very desirable. 3.0 Implementing pairs in CEP In this section we look at another type of constraint. We start with the assumption that variables are constrained by their relationship with other variables. For example, if a person ?p is to perform a job ?j then we could require ?p to be qualified to perform ?j. Often these relationships are represented using predicates. For example qualified_for(Mary,Java). A relationship between a set of variables may be static or dynamic in a given domain. Dynamic relationships can change over the length of a plan. For example, it might be possible for John to qualify for software testing. Static relationships are not affected by any of the operators in the domain and so cannot change over the plan. For example, it may be the case that none of the operators in the domain cause a person to become qualified or disqualified. In this case we can describe them as invariants [McLuskey & Porteous 97]. Planning theory has been developed with dynamic predicates in mind. For example, most planners use a complex modal truth criterion just so they can reason about the state of dynamic relationships in a changing plan. Static relationships are a special case. Complex modal truth criteria are not needed to reason about static relationships. However, most planners treat static relationships in the same way that they treat dynamic relationships. Often this is quite inefficient because plan reasoning carries a lot of baggage with it in order to deal with the difficult cases, though current work on plan compilation is now trying to take advantage of domain analysis to separate out simple from difficult cases [Long & Fox 97] Actually, one form of static relationship is treated efficiently in some planners. Static relationships with an arity of one are typing constraints and are treated as variable constraints in some planners. In most planners, variables are implemented as a constraint based reasoning system. So while the planner takes a very much try-it-and-see approach, which requires exponential time, variable constraints are processed using constraint propagation in polynomial time. One reason for this is that the planner has the difficult problem of reasoning 1. In the worst case, binding a variable will cause constraints to be propagated to every other variable. This will take O(n) time where n is the number of variables. These propagated constraints may then cause some other variable to bind. If every variable is eventually bound then the time isO(n2). If variables were not typed then the worst case time is O(n) because binding one variable cannot cause another to bind. So at first glance, the use of typing makes the task of binding a variable significantly more time consuming. However, in both cases the time per variable is the same O(n). So the time required by a planner to bind n variables assuming no backtracking is O(n2) independent of whether the planner uses typing or not. about change over time while the variable reasoning engine is only concerned with single values at single points in time. The proposal in this paper is that all static relationships should also be treated as variable constraints. For most planners, this will allow static relationships to be satisfied in polynomial time using constraint satisfaction rather than being solved in exponential time using goal achievement. For super complex planners, that would otherwise satisfy these relationships intelligently in polynomial time, we still get the advantage of avoiding the baggage of goal achievement. The implementation that we take in CEP is very simple. We assume that all the variables in a relationship are unbounded. If Mary is the only Java programmer then it is possible to reason that non-codesignating ?p with Mary also non-codesignates ?j with Java. Our assumption is that this reasoning is not that important because it will not be needed very often. It will be more common to reason that binding ?p to John, or any other value except Mary, non-codesignates ?j with Java. For simplicity, we also assume that most relationships between variables are binary. So, while CEP can reason about a person being qualified for a job it cannot reason about the safety of storing a chemical at a particular temperature in a particular container. Under these assumptions, a relationship between two variables can be represented as a set of pairs. The pairs represent the possible values that the variables can take. For example, the pair represents that Mary is one of the people that can program in Java. Relationships can also be represented by the pairs not in the relationship. For example, in a negative relationship, would represent that John is one of the few people who cannot drive. In the data structure for a variable, a record is kept of the pairing constraints which apply to that variable. The record includes the list of pairs in the relationship, whether this relationship is positive or negative and which side of the pair should match the variable. Pairing constraints, like typing constraints, are applied when a variable is created. We have not looked at using pairing constraints in conditional preconditions and it is not clear that this would make sense anyway. When a variable is bound, the pairs on that variable are simply translated into noncodesignation constraints. In the negative relationship above, if ?p binds to John then ?j is non-codesignated with Drive and all other jobs mentioned against John. In the positive relationship above, if ?p binds to Mary then ?j is non-codesignated with all jobs except Java and the other jobs mentioned against Mary. When two variables co-designate, the list of pairing constraints is simply unified. Pairing constraints are simply ignored when non-codesignation constraints are applied. Even though this implementation is very simple, it leads to performance gains in CEP. 4.0 Pairs in the modelling of chemical plant We have seen that the use of pairs is a general technique for allowing constraints between planning variables. However, pairs also turn out to be a valuable approach to some of the modelling problems raised by real-world chemical plant, the domain for which CEP was designed. In the discussion that follows, note that we refer to pairs in two contexts: generic pairs defined inside planning operators, and the plant-specific pairs which form part of the model of a plant and which are used during planning to instantiate the generic pairs. An aim of the INT-OP project was to develop tools and techniques which would allow a non-planning expert to set up a new domain description of a chemical plant for CEP to use in the generation of operating procedures for it. From a declarative perspective, a chemical plant consists of a (usually very large) set of components and connections: each component can be represented as a frame in an equipment hierarchy, while the topology is represented by specifying for each component to which other components it is immediately connected. It should be noted that components are instances of generic pieces of equipment such as valves, pumps or vessels, but topology is specific to a particular plant. Knowledge of both components and topology is easy to acquire through the same CAD system which is used to design the plant, and in the INT-OP project AutoCAD was used to automatically generate the data-structures required by CEP from the plant diagram [Aylett et al. 97]. It is much more difficult to acquire the procedural knowledge for the domain, that is, the behaviour of the plant. This knowledge is embodied in planning operators, which not only have to accurately model the behaviour of plant components, but also take into account the way in which the planning system itself functions. This dual role of planning operators can make them hard to define successfully even for experts in a particular planning system. The solution adopted in the INT-OP project depends on the assumption that the majority of the planning operators required for a particular plant embody the behaviour of generic components found as instances in the plant. Thus all valves or pumps of a particular type in the equipment hierarchy can be modelled in the same way. This may be summarised as the position ‘function is independent of structure’. It then becomes possible to develop a library of generic planning operators attached to the equipment hierarchy. The appropriate planning operators can simply be loaded for a domain containing the components with which they are associated without the constructor of the domain needing to understand their internal structure. So far we have generated 36 such generic operators [Petley et al. 98]. However in AI planning, there is always a risk that making planning operators more general will multiply the search effort required to instantiate them for a particular domain. This problem is acute for chemical process plant because not only are they highly interconnected, but where movement is the key planning primitive in a robot domain, chemical flow plays this role for process plant [Aylett et al. 98]. For a reaction to occur in one of the vessels in a plant, the correct chemical flows into it must be established, and each vessel may in turn create a chemical flow for other parts of the plant. Like robot movement, chemical flow is a routing problem, though a somewhat more complex one [Aylett et al. 98]. This routing problem is not handled by CEP itself, but by a specialised valve-sequencing sub-planner [Soutter 97]. However every use of a planning operator which invokes valve-sequencing must instantiate variables for the start and end points of the required flow. For example, the vessels known as formers in an ammonia plant require a supply of natural gas, which comes into the plant from an external source and flows through a number of pipes and valves to reach these vessels. A planning operator to start up a former in an ammonia plant must establish this flow of natural gas. Back-tracking across chosen start or end-points for a flow is particularly expensive because each time the valve-sequencer must be called to establish the new route. The interconnectedness of the plant means that there are always, in the absence of knowledge of the specific topology of the plant, many such choices. On the other hand, if knowledge of the specific topology of the plant is incorporated into planning operators, they cease to be generic. Thus a mechanism is required which allows knowledge dependent on topology to be represented in generic planning operators. Pairs offer just such a mechanism. Figure 1 gives an example of the use of a generic pair in a CEP operator (in bold).The first pair in Figure 1 means that when the operator instantiates the variables ?pilot and ?source the only possibilities will be the values used in the definitions for the plant-specific pair unitSource. In the given operator, a flow of fuel is required from a source into the pilot, and without the pair feature CEP would have to try all the possible sources during planning until one was found that was suitable. However, by using pairs, only the sources defined in a unitSource pair would be tried, and for the operator in Figure 1 only unitSource pairs whose first part was a piece of equipment of the pilot variety. A plant-specific pair is declared outside the operator in a pair definitions file. Figure 2 shows what these declarations would look like for the unitSource and the chemSupply pairs. In order to evaluate our hypothesis that the use of pairs supported the use of generic planning operators without these bringing an unacceptable loss in planning efficiency, a small experiment was conducted. pair (unitSource, PI1 : Input4). pair (chemSupply, Input4 : NaturalGas). FIGURE 2. Plant-specific pair declarations macro SupplyFueltoPilot { inlet ?source; vent ?vent; pilot ?pilot; chemical ?fuel; pair unitSource, ?pilot : ?source; pair chemSupply, ?source : ?fuel; solve supplyFuel(?fuel, ?pilot) is true; nodes 1 instant flowOfChemical; 2 instant pressureControl; 3 instant stopVenting; order 1, 2, 3, $; require 1, 2 flow(?source, out, ?vent, in, ?fuel, fill); 2, $ > flow(?source, out, ?pilot, in, ?fuel, fill); 3, $ noFlowUpstream(?fuel, ?vent, in); end } FIGURE 1. Plant-specific pair declarations The domain used was that of the Double Effect Evaporator (DEE), a test rig used for teaching at University of Loughborough and discussed in [Aylett et al. 97]. In summary, the plant takes an input of brine and extracts the salt by means of evaporation, with steam generated in the first evaporation process used to drive a second. The top-level operator for this domain, a macro operator which generates the procedure to start the whole plant, was implemented in three versions: firstly as an operator including specific plant knowledge (Figure 3); secondly as a generic operator without the use of pairs (Figure 4); and finally as a generic operator with pairs (Figure 5). Note the differences between these three versions: in the first, specific plant components are referenced thus HE1 is the particular heat exchanger in this plant. In the second version, specific references to actual plant components have been replaced by generic variables for the classes of components found in a plant of this type. These are now declared using types in the macro header (differences and additions in bold). In the third version, the first two pairs establish, together with the inequalities above them, that two different heaters are required, one for each evaporator. Pair 2 then identifies a catchpot as linked to the first heater and a condenser as linked to the second heater. In order to even out variations on the Sun Sparc5 being used to run this domain the problem was run 10 times for each version of the planning operator. The results can be seen in Table 1 above. It can be seen that a high penalty of an over 35% increase in planning time is paid for the generic operator without pairs. This is striking given that 20 planning operators are needed in all for this problem and the final plan contains 236 steps. However, once the macro StartDoubleEvaporator { chemical ?chem; solve startDouble(E2) is true; nodes 1 instant createChemical; 2 instant activateEvaporator1; 3 instant heatPlant; 4 instant activateSprayCondensor; 5 instant activateEvaporator2; 6 instant activateHeater2; require 1, $ create(MT1, ?chem, ls) is true; 2, $ > active(E1) is true; 3, $ > active(HE1) is true; 4, $ active(SC1) is true; 5, $ active(E2) is true; 6, $ active(HE2) is true; 6, $ active(CP1) is true; order 1,2,3,4,5,6,$; achieve $, @ startDouble(E2) is true; end } FIGURE 3. A Non-generic operator TABLE 1. Results of Using Pairs Operator Planning Time